This feels a little like moving goal posts. This was moved to wip because it didn't build for RISC-V and would break the CI. Both of those issues are fixed. But now it has to include a custom build infrastructure.

The newlib path issue could easily be fixed by not using the version in the path, which is probably a good idea anyway.

I will have a look at re-implementing the build system, but I feel that this could be accepted in the meantime.

I created #443 to help with the hardcoded version paths

I also updated this to use TockLibrary.mk which should address the current issue

This builds locally for me, in the CI I see

 (insn 179 178 46 8 (set (reg:SI 3 r3 [168])
        (mem/u/c:SI (plus:SI (reg:SI 12 ip [169])
                (unspec:SI [
                        (symbol_ref/u:SI ("*.LC1") [flags 0x2])
                    ] UNSPEC_PIC_SYM)) [0  S4 A32])) "../../../examples/lora/RadioLib/src/modules/LR11x0/LR11x0.cpp":629:16 929 {*thumb1_movsi_insn}
     (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LC1") [flags 0x2])
        (nil)))
during RTL pass: postreload
../../../examples/lora/RadioLib/src/modules/LR11x0/LR11x0.cpp:641:1: internal compiler error: in extract_constrain_insn, at recog.c:2195
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make: *** [../../..//TockLibrary.mk:175: ../../..//examples/lora/RadioLib/build/cortex-m0/RadioLib/examples/lora/RadioLib/src/modules/LR11x0/LR11x0.o] Error 1

So maybe a GCC bug in older versions that pops up when not using the cmake infrastructure? Thoughts @bradjc?

Okay, so this builds with libtock-c's Makefiles and with RadioLib's cmake? Is there a good reason for us to keep using cmake if the libtock-c Makefiles work?

The cmake is a useful fall back. It's part of the RadioLib CI and tested regularly. The Tock system hits a GCC bug so it's isn't as robust

It's fine to build with cmake out-of-tree, but we need PIC with our build system and want to avoid the overhead of supporting multiple build variations upstream.

Yeah, the cmake uses PIC as well.

The Tock system fails to build the LR11x0 module in the CI due to some GCC bug. So it's worth keeping the cmake around as an option for people who want to use the LR11x0 module.

Hmm.. I'm of two minds on the cmake issue.

I do think there is probably some utility in an example that shows how one could integrate libtock with an external build system, but I'm also very wary of keeping anything like that around as a first-class example that we have limited control over and an obligation to support :/.

If we keep it around, I'd want CI to test it. I also have gone through Herculean efforts to ensure that minimal/standard tooling (i.e. just vanilla make) is all that is needed to get up-and-running with Tock, which we've gotten a ton of positive feedback on over the years as a design choice, and requiring cmake would run against that. I also try very hard to make sure that anything that runs as CI in the cloud is 'easy' to run locally; though there it's probably easy to follow a path similar to qemu where the local CI can run it, but wouldn't pull it in by default.... /endStreamOfConsciousness

I think I lean at the moment towards:

• We should include the cmake as example
• It should be built in a separate, non-required-to-merge "third-party-build" or similar CI job; this lets us see when something goes awry, while de-risking a third-party change holding up core development

I removed the cmake option

Ping!

It would be great to get this merged so then #456 can go ahead

Ping!

Ping!